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ABSTRACT 



A software-based computer security enhancing process and graphical software- authenticity 
5 method, and a method to apply aspects of the two are disclosed. The process provides protection 
against certain attacks on executable software by persons or other software used on the computer. 
Software using this process is protected against eavesdropping (the monitoring of software, 
applications, the operating system, disks, keyboard, or other devices to record (steal) 
identification, authentication or sensitive data such as passwords, User-ID' s, credit-card numbers 

10 and expiry dates, bank account and PIN numbers, smart-card data, biometric information (for 
example: the data comprising a retina or fingerprint scan), or encryption keys), local and remote 
tampering (altering software to remove, disable, or compromise security features of the altered 
software) examination (viewing the executable program, usually with the intent of devising 
security attacks upon it), tracing (observing the operating of an executable program step-by- step), 

1 5 and spoofing (substituting counterfeit software to emulate the interface of authentic software in 
order to subvert security) by rogues (eg: Trojan Horses, Hackers, Viruses, Terminate-and-stay- 
resident programs, co-resident software, multi-threaded operating system processes, Worms, 
Spoof programs, key-press password capturers, macro recorders, sniffers, and other software or 
subversions). Aspects include executable encryption, obfuscation, anti-tracing, anti-tamper & sclf- 

20 verification, runtime self-monitoring, and audiovisual authentication (math, encryption, and 
graphics based method permitting users to immediately recognise the authenticity and integrity of 
software). Fig. 5 in the specification depicts the many components and their interaction. 
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Invention Title: 



Computer software authentication, protection, and security 
system 



The following statement is a full description of this invention, including the best method of 
performing it known to me:- 



COMPUTER SOFTWARE AUTHENTICATION, PROTECTION, 
AND SECURITY SYSTEM 



Background Of The Tnvemi^ 
5 The present invention relates to a computer program having enhanced security features, 

and aiso to a system and method for enhancing the security features of a computer program. In 
particular, the present invention relates to such a program, and the system and method for 
creating the program, having increased security features to prevent ID data (as defined) 
eavesdropping and/or theft and/or to ensure authenticity. 

10 

Description Of The Prior Aft 

Computers are becoming widely interconnected and heavily relied upon to process and 
store sensitive information. The risk of unauthorised access to computers and information has 
increased with this increased interconnect! vky . 

15 Many security advances exist in the areas of identification & authentication of users, 

cryptography, virus prevention, and the like, however - almost all of these advances ultimately 
rely upon computer software. Most computer systems are, or are accessed by, small personal 
computers, and most software used on these personal computers is susceptible to "local attacks" 
- attacks which are mounted from inside said personal computers against said software by other 

20 software or people. 

Passwords, User-ID s, credit-card numbers and expiry dates, bank account and PIN 
numbers, smart-card data, biometric information (for example: the data comprising a retina or 
fingerprint scan), cryptographic keys, and the like, are all examples of identification, 
authentication or similar data which is ehher sensitive in itself, or may allow access to sensitive, 

25 restricted or other information or services. Hereafter, the terra ID-Data will be used to refer to 
the abovementioned identification, authentication or similar data, excluding ID-Data which is 
valid only for a single use, or which is designed to expire at regular intervals of short periods of 
time, say less than two minutes. 

Illegal access to computer system information can be obtained by exploiting various 

30 security flaws found in computer software products. A common flaw is the susceptibility of said 
software to the theft of ID-Data either directly from said software as it executes, or, from the 
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operating system or hardware on which said software is executing. Another common flaw is the 
susceptibility of said software to (illegal) modification. Such modifications may remove, disable, 
or compromise the security features of said software. 

Viruses, Terminate-and-stay-resident programs (TSRs), co-resident software, multi- 
5 threaded operating system processes, Trojan Horses, Worms, Hackers, Spoof programs, key- 
press password capturers, macro-recorders, sniffers, and the like can be effective at stealing ID- 
Data and are examples of (a) rogue software, (b) people capable of subverting security software, 
or, (c) software which can be configured for illegitimate purposes. Hereafter, the term rogue 
software will be used to refer to software or subversions such as the above mentioned (a) (b) and 

1 0 (c), used for the purpose of stealing ID-Data. The definition of our term "rogue software" when 
used herein also includes software or other means used to tamper with other software. The term 
tampering is defined hereafter. 

There are many ways to introduce rogue software into a computer system. Viruses 
spread automatically by introducing themselves. Trojan-Horses are usually introduced by 

1 5 tricking users into allowing them to execute (such as by masquerading as a new or well-known 
computer game or other product). Existing security problems may be utilised to introduce rogue 
software; some well known problems include Java bugs, errors, or oversights, ineffective 
physical security (for example: permitting rogue software to be introduced directly on floppy disk 
by an intruder), electronic mail attachments which automatically execute or execute after a 

20 simple mouse-click, incorrect security settings on internet, world-wide-web, TCP/IP or modems, 
and tampering (see definition hereafter) with legitimate software in-transit as it flows from 
remote internet sites into a users computer, to name a few. 

Rogue software, once introduced, can steal ID-Data as mentioned hereinbefore. It may 
monitor keyboard (for example: by recording every key, as the user presses each one, in order 

25 to steal a password as it is being typed in), serial-port, mouse, screen, or other devices to steal 
ID-Data directly from them. It may monitor other software, applications, the operating system, 
or disks to steal ID-Data from there also. Once stolen, this ID-Data may be stored locally (for 
example: in memory or on-disk) or transmitted to remote locations (for example: by modem or 
network) or used immediately to perform illegal operations. Hereafter, the term eavesdropping 

30 will be used to refer to the monitoring of a computer to record ID-Data. 

For example, a key press recorder could secretly, and unbeknown to the computer user. 
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record all the keys pressed by the user into a hidden systems file. The information recorded 
could include a user's password and other sensitive information which an organisation would 
obviously wish to protect. 

Additionally, rogue software may remove, disable, or compromise existing computer 
5 software security features by modifying the memory, disk, or other image of said computer 
software. Rogue software may also utilise tampering techniques to alter existing computer 
software in order to steal ID-Data from it, or may attach itself to existing computer software (as 
is the case with many computer viruses). Hereafter, the term tampering will be used to refer to 
the abovementioned modification of computer software. Tampering may take place either locally 

1 0 (within a users PC) or remotely (for example: at one of the points which a computer program 
passes through as it is being download). 

Further, counterfeit software can be substituted for legitimate software. The counterfeit 
will appear real to a computer user, but actually acts to subvert security, such as by stealing ID- 
Data. Sometimes called "Spoof programs or Trojan Horses, counterfeit software of this type 

1 5 may invoke the original legitimate software after having stolen ID-Data, so as not to arouse a 
user's suspicion. 

Another potential security flaw found in computer software products is susceptibility to 
examination and reverse-engineering. Known (but generally secret) and other security problems 
or mistakes can be discovered by hackers and the like from the examination of existing computer 
20 software and by tracing its operation. 

Additionally, Computer software piracy is a growing problem, and the existing simple 
means which prevent this problem (such as registration or serial numbers and customer-names 
being encoded within the product) are becoming less effective. 

There is necessity within the try-before-you-buy software market for vendors to employ 
25 effective features which allow old software to expire without fear of hackers or the like removing 
said expiry features and for secure registration of software to be provided through the use of 
software unlock-codes 

There is also need for software to be able to prevent security attacks upon itself (ie: 
tampering) and upon its own attack-detection code. There may also be a future need for 
30 software to identify the attacker for subsequent prosecution. 

There also exists cases where untamperable software usage metering may be desirable. 
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and where effective password-protection of software execution may also be desirable. 

Known advances in certain areas of computer security have been successful and 
documented. There have been some advances in anti-virus technology which help detect and 
prevent certain security problems. There have been numerous advances in hardware-assisted 
5 computer security add-ons and devices, such as smartcards and biometnc input devices. There 
have been advances in cryptographic techniques. Generally, all of these advances require 
authentic, un-tampered-with computer software in order to work. There have been relatively 
few advances in software-based integrity self-checking (eg: tamper protection), and no prior 
software-based advances in preventing eavesdropping or the electronic theft of ID-Data, and no 
10 prior software-based advances in self-authentication. 

$urrimarv Qf The Invention 

This invention seeks to provide computer software having enhanced security features, 

to a process which substantially enhances the security of computer software (hereafter referred 
15 to as the improved process) and to a method by which to apply said improved process (hereafter 

referred to as the applicator). 

The improved process consists of including computer code to automatically detect 

tampering of said computer software, and computer code to prevent the theft of ID-Data by 

replacing existing vulnerable (to rogue software eavesdropping or attack) software or operating 
20 system code with secure equivalents which utilise anti-spy techniques (as described later in this 

document). 

Preferably, the improved process also consists of including computer code to prevent de- 
compilation, reverse-engineering, and disassembly by the inclusion of obfuscating code inserts, 
and the use of executable encryption. 

25 Preferably, the improved process also consists of including code to prevent execution- 

tracing and debugging by the use of code designed to detect and prevent these operations. 

Preferably, the improved process consists of, or also includes, human -recognisable audio- 
visual components which permit the authenticity of said computer software to be easily verified 
by the user on each invocation using techniques described later in this document. 

30 The idea which lead to the creation of this invention can be summarised as follows:- If 

a piece of computer software that is executing can be shown to be the genuine article, and this 
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software can protect itself against eavesdropping, and this software can prevent tampering of 
itself, then is it possible for this software to function in a secure manner, even within an insecure 
operating system. This invention permits the creation of such a piece of computer software - 
having a tangible, useful security advantage and hence improving its value. 

5 

Brief Description Of The Drawings 

The present invention will become more fully understood from the following detailed 

description of preferred but non-limiting embodiments thereof, described in connection with the 

accompanying drawings, wherein: 
1 0 Fig. I illustrates the standard operation of a computer system known in the prior art; 

Fig. 2 illustrates the known operation of a rogue or "spoof program; 

Fig.3 illustrates application code updated with the preferred embodiment; 

Fig. 4 illustrates the known operation of a rogue eavesdropping program; 

Fig. 5 illustrates the interaction of the components of the updated application; 
1 5 Fig 6 illustrates the general structure of the preferred embodiment of the applicator; 

Fig. 7 illustrates a standard layout for a program to be executed on a computer system; 

Fig. 8 illustrates the standard layout of an EXE header under the MS-DOS operating system. 

Fig.9 illustrates a standard layout of an EXE program under MS-DOS; 

Fig 10 illustrates an altered executable form constructed in accordance with the specific 
20 embodiment; 

Fig. 1 1 illustrates a first stage of execution of the new.exe executable, 

Fig 12 illustrates a second stage of execution of the new.exe executable file; and, 

Fig. 13 illustrates a third stage of execution of the new.exe executable file. 



25 Detailed Description Of Preferred FmhmWm* 

Throughout the drawings, like numerals will be used to identify similar features, except 
where expressly otherwise indicated. 

As will be described hereinafter, the present invention has general applicability to many 
different operating systems including Microsoft DOS (Trade Mark), Apple Macintosh Operating 
30 System, Unix (Trade Mark) etc. 

Described hereafter are several security-enhancing techniques to combat eavesdropping. 
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Security is provided by (a) hampering examination of software-code or operating system code 
or parts thereof through the use of the encryption or partial encryption of said code, (b) 
preventing the disassembly of said code through the inclusion of dummy instructions and prefixes 
and additional code to mislead and hamper disassembly (ie: obfuscating inserts), (c) preventing 
5 the computerised tracing of the execution of said code (for example: with code debugging tools) 
through the use of instructions to detect, mislead, and hamper tracing, (d) preventing tampering 
of said code through the use of scanning to locate alterations, either or both on-disk and in 
memory either once at the start of execution, or continuously upon certain events, or (e) 
preventing ID-Data theft through the inclusion of secure input/output routines (for example: 

10 routines to bypass the standard operating system keyboard calls and use custom-written higher- 
security routines as a replacement) to replace insecure computer-system routines. Hereafter, the 
term anti-spy will be used to refer to any combination of one or more of the abovementioned 
techniques [(a) through (e) or parts thereof) used to prevent eavesdropping. 

Referring now to Fig. 1 there is illustrated the standard scenario for "running" a given 

15 executable program 16, under the control of a computer operating system 17 on a computer 18. 
In the preferred embodiment of the present invention, the executable program 16 is subjected to 
modification, as will be described hereinafter, to ensure its integrity and improve its security. 
There are five aspects of this inventions improved process, although said process is still 
substantially improved even if not all of them are present. These aspects are: (1) Preventing 

20 eavesdropping (2) preventing disassembly and examination (3) detecting tampering (4) 
preventing execution-tracing and (5) ensuring authenticity. 

Preferred embodiments illustrates each of these aspects of the present invention will now 
be described. 

25 Aspect 1 Preventing eavesdropping 

As hereinbefore described, it is desirable to prevent rogue software from eavesdropping 
on ID -Data. By replacing software which is vulnerable to eavesdropping with equivalent 
software which is far more secure, this purpose is achieved. To remove the vulnerability from 
the secure equivalent software, replacement routines may communicate directly with the 

30 hardware of the computer (for example; they may communicate with the keyboard circuitry 
instead of using the system-supplied (and hence possibly insecure) application interface 



keyboard-entry function-calls.) while disabling system interrupts which would permit rogue 
software to eavesdrop. Said replacement routines are coded to store ID-Data retrieved in a 
secure manner. ED-Data is not stored in full in plaintext (ie: unencrypted) in system or application 
buffers. 

5 

Aspect 2 Preventing disassembly and examination 

As hereinbefore described, it is desirable to hamper disassembly (or de-compilation or 
reverse engineering) to protect software against eavesdropping and tampering, and to hinder 
examination of said software which might lead to secret security problems or mistakes being 
10 disclosed. 

Obfuscating inserts can successfully prevent automatic disassembly. Obfuscation is 
achieved by following unconditional jump instructions (for example, Intel JMP or CLC/JNC 
combination or CALL (without a return expected) or any flow-of-control altering instruction 
(which is known not to return to the usual place) with one or more dummy op-code bytes which 
1 5 will cause subsequent op-codes to be erroneously disassembled (for example, the Intel OxEA 
prefix will cause disassembly of the subsequent 4 op-codes to be incorrect, displaying them as 
the offset to the JMP instruction indicated by the OxEA prefix instead of the instructions they 
actually represent). 

Dummy instructions may also be included to hamper disassembly by deliberately 
20 misleading a disassembler into believing a particular flow of control will occur, when in fact it 
will not. 

Flow of control can be designed to occur based upon CPU flag values determined from 
instructions executed a long time ago. Together with tracing prevention, this makes manual 
disassembly nearly impossible. 
25 The majority of the executable portions of the software can be encrypted for external 

storage. The decryption taking place in- memory after the software is loaded from external 
sources, under the control of a decryption "header" which prevents its own tampering and 
disassembly etc. This makes manual and automatic disassembly nearly impossible, since the 
decryption should be designed to fail if tampering or tracing is detected. 

30 



Aspect 3 Detecting tampering 

As hereinbefore described, it is desirable to detect tampering, since this may lead to the 
reduction of software security. 
5 This can be achieved with the use of code which is protected from disassembly and 

examination through obfuscation and encryption, which re-reads its own external-image and 
compares it with its known memory image or precalculated check- data to detect hot-patching 
(ie: the modification of software sometime after it Has been loaded from disk, but (usually) before 
execution of the modified section has commenced). 
1 0 Additionally, the software can scan the memory image of itself one or more times, or 

continuously, to ensure that unexpected alterations do not occur. 

Certain modifications to the external copy of software are reflected in subtle changes to 
the environment in which the modified software will be executed (for example: the size of the 
code, if altered, will be reflected in the initial code-size value supplied to the executing program 
1 5 being incorrect ). Additionally, certain modification to the operating system and environment 
of said software can also be monitored (for example: certain interrupt vector table pointers in 
Intel-processor applications) to detect unexpected changes by rogue software. These changes 
can also be detected to prevent tampering. 

Once tampering is detected, program flow-of-control needs to be changed so that the 
20 potential compromise associated with ID-Data theft is avoided. This may be the security- 
enhanced program terminating with a message indicating that its integrity has been compromised 
before all of the ID-Data is entered. Alternatively, the fact that tampering has been detected may 
be kept secret and the ID-Data retrieved, however, immediately upon retrieval \ the ID-Data 
entered can be invalidated thus preventing access to that which the now potentially compromised 
25 ID-Data would have otherwise allowed. This latter method allows for the possibility of security- 
enhanced software informing remote or other authorities that tampering was detected and 
possibly other information, such as what specifically was altered and by whom. Care must be 
taken to ensure the integrity of the "remote-informing" code before ID-Data entry is permitted. 
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Asnect 4 Preventing execmion-trarinp 

Apart from "spoofing" (described in aspect 5 hereafter) the last resort of a rogue who 
is prevented from disassembly, tampering, and eavesdropping on software is to trace the 
5 execution of said software in order to facilitate the compromise of its security. Hampering 
tracing (tracing is sometimes called debugging) prevents this. 

There are numerous methods of detecting a debug-environment (ie: when tracing is 
taking place). When combined with decryption and tamper-protection as hereinbefore described, 
it makes the rogues task of detecting and bypassing debug-detection extremely difficult. 
1 0 Reference and examples to Intel and MS-DOS environments follow hereafter, although it will 
be apparent to one skilled in the art that these and similar methods are applicable on other 
platforms. 

Standard Intel x86 interrupts 1 and 3 are used by debuggers to facilitate code tracing. 

By utilising these interrupts (which are not normally used by normal applications) in security- 
15 enhanced software, it hampers debugging, since built-in debugging functions are now not 

automatically available. 

Monitoring the system timer to determine if software execution has spent too long 

accomplishing certain tasks can detect a situation where code tracing has been in effect and a 

breakpoint was reached. 
20 Disabling the keyboard will hamper debuggers, since tracing instructions are usually 

issued from the keyboard. Similarly, disabling other places from where tracing instructions are 

usually issued (eg: serial ports, printer ports, and mouse) or displayed (eg: screen) will also 

hamper tracing. 

System interrupts can be re-vectored for use within the secure software to perform tasks 
25 not usually performed by those interrupts. Debuggers usually rely upon system interrupts also, 
so to do this would usually disable or destroy a debugger being used to trace the software. 
Disabling interrupts and performing timing-sensitive instructions between them will further 
hamper debugging. When tracing software, instructions are usually executed one-at-a-time in 
order for the user to understand their operation. Many system interrupts must occur regularly 
30 (eg: timer and memory re-fresh operations), so debuggers usually do not disable interrupts even 
when they encounter an mterrupt-disabling instruction. If timers and the like are re-vectored in 
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two separate stages, any timer (etc) interrupt occurring in between the two stages will fail, and 
usually crash the computer. Further, interrupts can be disabled or enabled using obscure means 
(with flag-altering instructions for example) to hamper tracing. 

Discretely testing the status of disabled or enabled system facilities (eg: interrupts, 
5 keyboard, vector-pointers) to ensure that a debug-environment has not altered or by-passed them 
will seriously hamper tracing also. 

Certain computer processors have instruction caches. In some circumstances, it is 
possible to alter the instructions immediately before the CPU encounters them, but the altered 
instruction will not be executed normally because the cache copy has the "old" one still In 
10 debug environments, the cache is usually flushed, so any altered instructions will actually be 
executed. This again hampers tracing 

Using strong cryptographic schemes, such as DES, or RSA or the like will prevent the 
examination of any decryption routines from revealing a simple patch to disable said routines. 
When tracing software, the program stack is usually used by the debugger either during the 
1 5 tracing operations or at other times. This is easily detected, and by using the area of the stack 
which will be destroyed by unexpected stack-use for code or critical data, software can be 
designed to self-destruct in this situation. 

Scanning the command environment and the execution instruction can detect the 
execution of software by unusual means. Searching for "DEBUG" in the command line, or 
20 scanning memory for known debuggers for example will detect tracing. Additionally, by 
detecting which operating system process initiated the load of the software, unexpected 
processes (eg: debuggers) can be detected. 

Monitoring system buffers (eg. the keyboard memory buffer) or hardware (eg: the 
keyboard circuity and internal buffers) for unexpected use (eg: keyboard input and processing 
25 is occurring when the software is not requesting it) will also detect debuggers, which usually rely 
in part on system functions in order to operate. 

Building a process or multiple processes which are traditionally difficult to trace, such 
as a resident or child process which executes during system interrupts or after the parent process 
has terminated will again hamper tracing. 
30 Bypassing system routines (eg: in DOS, using direct memory writes instead of DOS 

system calls to revector interrupts) will further hamper debugging and rogue software 
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monitoring, as will unravelling loop constructs (which will make tracing long and cumbersome). 
Code checksums and operating-system checks (eg: interrupt table pointers) can be designed to 
detect debug-breakpoint instruction inserts or other modifications. Using the result of the 
checksum for some obscure purpose (eg: decryption, or (much later) control-flow changes) will 
5 further hamper tracing. 

It will be apparent to one skilled in the art of low-level software programming that a 
combination of techniques to detect, prevent, and mislead tracing will provide a mechanism 
making tracing very difficult, if not impossible. At the very least, it will require an expert with 
very expensive tools and perhaps some understanding of the original software design a very long 
10 time to make any debugging progress - a situation which is recognised in military software 
security accreditation worldwide as highly desirable. 

Aspect 5 Ensuring authenticity 

In accordance with an aspect of the present invention there is provided a method of 

1 5 providing for a secure entry of ID-Data in a computer system comprising activating a visual 
display or animation and/or audio feedback (hereinafter called an audio/visual component) as pan 
of said secure entry of ID-Data so as to hamper emulation of said secure entry process. 
Preferably, the animation includes feedback portions as pan of the ID-Data entry process 
Preferably, the animation is repeatable and varied in accordance with the information entered. 

20 The animation preferably comprises 2.5D or 3D animation and includes animation of any ID- 
Data input. 

Preferably, the ariimation is designed to tax the computer resources utilised and thereby 
making any forgery thereof more difficult. 

It will be apparent to one skilled in the art of low-level software programming that the 

25 five aspects described herein may be combined to provide substantially stronger security than any 
aspect taken on its own. For instance, to combine tamper-detection with encryption, the 
precalculated check-data as derived during tamper-detection described hereinbefore may actually 
be one part of the decryption-key which is required to successfully decrypt the remaining 
executable software. If prevention-of-tracing and environment characteristics (including 

30 debugger detection as described hereafter) are additional portions of said decryption-key, it 
makes the detennmation of said decryption-key by any person or computer program other than 
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the secure original an extremely difficult, if not impossible, task. 

Further, it will also be apparent to one skilled in the art of low-level software 
programming that a simple construct such as a JNE to alter program flow-of-control after 
tampering has been detected is insufficient, since the JNE construct itself is subject to tampering. 
5 The denryption process described hereinbefore is preferable since there is no single point of 
alteration that can possibly yield a tampered executable that would execute. Indeed, the 
executable protected with encryption will not even be transformed into its intended form if 
tampering is detected. 

10 General Description of Preferred Embodiment (si 

Notwithstanding any other forms which may fall within the scope of the present 
invention, preferred forms of the invention will now be described, by way of example only, with 
reference to the accompanying drawings. 

In the preferred embodiment of the present invention the user interface for the acquiring 

1 5 of ID-Data is secured whereby the duplication of the interface is rendered mathematically 
complex such that cipher-code breaking techniques are required to produce a counterfeit look- 
alike interface. By making the authentication interface (ie: ID-Data entry screen - for example: 
a logon screen or a screen for entering credit card details) unable to be emulated, tampered with, 
or reversed engineered, the application program allows for a higher degree of security and 

20 authenticity even in insecure environments such as the Internet or home software applications. 
Referring now to Fig.2, there is illustrated a classic form of rogue attack on a computer system. 
In this form of rogue attack, a rogue's "spoof program 22 is inserted between application 
software 16 and the user 23. The application 16 normally has a portion 24 devoted to ID-Data 
entry and verification or the entry of commercially sensitive information (including passwords 

25 etc) to the application in addition to the application code 25. The spoof program 22 is designed 
to exactly reflect the presented user interface of ID-Data entry code 24 to the user. The user 23 
is then fooled into utilising the masquerading spoof program 22 as if it was the application 16. 
Hence the user can be tricked into divulging secret information to the spoof program 22. An 
example may include a classic "login spoof wherein the spoof program 22 prints the login 

30 prompt (ie: ID-Data entry) message on the screen and the user mistakes the login prompt for a 
legitimate one, supplying a user name and password to this program 22 which records this 
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inforrnation as well as passing it on to the login code 24 of application 16 so as not to arouse the 
suspicion of user 23 - or by issuing a message, such as "incorrect password, please try again" and 
then passing control to the login code 24 of application 1 6. ■ 

Referring now to Fig.4, there is illustrated a relatively new form of rogue attack 40. This 
5 form of attack proceeds sirnilarity to the spoof attack of Fig.2, with the following difference. 
Instead of a spoof program 22, a rogue program 4 1 is inserted which secretly eavesdrops on ID- 
Data entry code 24, or on application code 25, or on operating system 1 7, or on hardware 1 8 
or elsewhere in order to steal sensitive information directly from the legitimate application. Since 
the legitimate application is still actually executing, the users suspicion is not aroused, since 

1 0 rogue program 41 is generally invisible to the user 23. Alternatively, executable program 1 6 may 
have been tampered with (as hereinbefore described) to reduce its security, alleviating the 
necessity for the presence of rogue program 41. 

In Fig. 5, there is illustrated in detail the structure of an application 50 constructed in 
accordance with the preferred embodiment running on computer hardware 18. Fig. 5 is similar 

15 to Fig.4 with the important difference that user 23 now communicates direcdy with secure 
drivers 5 1 which are part of the secure ID-Data entry program code 3 1 which is utilised by the 
security-enhanced (eg: tamper protected) application code 52. It can be seen that the user 23 
no longer communicates with the operating system 17 or the unprotected computer hardware 
1 8, thus the rogue program 41 can no longer eavesdrop on ID-Data 

20 In Fig.3, there is illustrated, in more general terms than Fig. 5, the structure of an 

application 30 constructed in accordance with the preferred embodiment wherein secure ID-Data 
entry program code 3 1 is provided which is extremely difficult to replicate, eavesdrop upon or 
subvert. The secured ID-Data entry program code 31 can be created, utilising a number of 
different techniques. 

25 Firstly, the executable portion of the secured ID-Data entry code can be protected against 

tracing, disassembly, tampering, viewing, reverse engineering, keyboard entry theft, 
eavesdropping, hot patching and other attacks by u-ansforrning the secured ID-Data entry 
program code 31 from its normal executable form 16 (Fig.2) to a corresponding secured form 
of executable (as hereinbefore described - refer aspects 1 to 4). These techniques are preferably 

30 applied to the appbeation code 1 6 in general or less preferably specifically limited to the ID-Data 
entry portions 24 thereof 
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Additionally, the secure ID-Data entry program code 31 is itself created. This code 3 1 
preferably comprises a complex graphical user interface series of screens and animation designed 
to make duplication by a rogue thereof extremely difficult. 

Initially, the complex user interface should include facilities to disable any frame buffer 
5 recording devices, the disablement occurring before each frame is displayed. Also, where a multi- 
tasking operating system is in use, or where context switching is enabled, switching out of the 
interface screen is preferably disabled or ID-Data entry procedures encrypted or terminated when 
the interface screen is swapped out. The images presented which form part of the ID-Data entry 
screens comprise complex 3D animation sequences having a high degree of complexity and 
10 extensive use of screen colours and screen resolution in addition to visual design so as to make 
copying thereof extremely difficult. 

The complex computer graphics can be created utilising standard techniques. For 
information on how to create complex 3D imagery, reference is made to "Computer Graphics, 
Principles and Practice" by Foley, Van Dam et al, published 1 990 by Addison-Wesley Publishing 
1 5 Company or other standard textbooks on generation of computer graphics. Reference is also 
made to the numerous internet news groups and archives on graphics and games programming, 
specifically to. comp.graphics.research, comp. graphics. rendering, comp.graphics.raytracing, 
comp.graphics.misc, comp graphics digest, comp.graplucs.animauon, comp. graphics. algorithms, 
comp. graphics, alt.graphics.pixutils, alt. graphics, rec.games.programmer, comp. sys. programmer, 
20 comp. sys. ibm. programmer, comp. sys. ibm.pc. programmer, comp.os rnsdos. programmer, 
comp. msdos. programmer, alt. rnsdos. programmer. Reference is also made to "PC Games 
Programmers Frequently Asked Questions" document available on the internet, via 
rec.games.programmer and elsewhere. 

By encoding a complex 3D image which forms part of the ID-Data entry screens, the 
25 hurdle requirement of a rogue to reverse engineer the complex imagery is substantially increased. 
The inclusion of graphical animation is advantageous in preventing static screen shot duplication 
attacks by a rogue form succeeding. 

As noted above, it is preferable that traditionally difficult graphical programming 
techniques are employed wherever possible, with the aim of making it more detectable for a user 
30 interacting with the system to discern lesser copies of the animation. Suitable 3D animation can 
include the introduction of shadows, the lighting of pseudo-3D animated objects, transparent or 



translucent objects, shiny, reflective, or mirrored objects, gravitational effects in animated 
objects, single-rrnage-raiKJom-dot-stereogram bitmaps or backdrops, translucent threads, effects, 
such as diffraction patterns, screen masks, backdrops, colour palette "animation", complex 
animated objects resistant to simple hidden-surface removal techniques known to those skilled 
5 in the an and directed to hindering duplication. 

Further, the animation can take into account: 

1 Thwarting attempts at compression of the ID- Data entry screens This can be 
achieved by having animation which has low visual entropy and having many graphical elements 
which are altered from frame to frame in a manner which is highly discernible to the human 
1 0 viewer. Apart from being difficult to replicate, complex 3D computer imagery having low 
entropy or redundancy will require large amounts of storage space for a rogue attempt at 
duplication based on recording the screen output and therefore be more readily discernible to the 
user should this form of attack be mounted. 

2. The animation is further preferably designed to thwart a successful replay attack which 
1 5 is based on providing only a subset (limited number of frames) of the screen animation to a 

viewer. This can be achieved, for example, by the inclusion of several animated spheres which 
"bounce" around the screen and change colours in a manner that is recognisable to the viewing 
user but which is not readily repeatable. A replay of only a subset of the screen animations to 
the viewer will be highly evident in this case when, upon looping, the user is alerted to a problem 
20 when the animation "skips" or "jumps" and does not operate in a previously smooth manner. 
This makes it difficult for a rogue spoof program to copy the animation without including all 
parts of it. 

3. Most importantly, the graphics presented can be customised to the input data entered. 
For example, the information entered by a user can be rendered and/or animated by the secure 

25 ID-Data entry program code 3 1 (Fig.3). As an example, in an ID-Data entry program, when a 
user types in their user name, the animation can be created letter by letter. For example, when 
typing in the user name "CHRIS" each letter could be rendered differently depending on those 
characters previously typed. For example, the letter "I" might appear as a large "barbers-pole" 
which spirals and changes colour, speed, size, and/or position and is slightly transparent, thereby 

30 allowing the animated seen which is a backdrop to the character to be discerned through the 
character itself For example, in the above example, the letter "1" would only appear as the 
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specific animated barbers pole thai is does if the previous letters entered were "C", "H", and "R" 
respectively . 

The utilisation of a unique sequence of animat ion based on a user's input of information 
sensitive data increases the difficulty of creating any "spoof program" attack on the application 
5 30. This is especially the case since the executable code of application 30 is preferably in an 
encrypted form. The use of animation being particular to the order in which characters are 
entered is particularly advantageous as the computational complexity of replication is 
substantially increased. 

A similarly effective animation technique is to produce only one graphical object after 
10 entry of each portion of ID-Data, such as a computer-generated human's face, but have the 
features of said face be determined by a hash or cryptographic function based upon the users 
input. For example, after entry of the ID-Data "CHRIS" (in this example, the individual 
characters may not, themselves, be based on the abovementioned generation procedure) , a 
teenage girTs face with long blonde hair and blue eyes may be displayed. If the "S" was instead 
1 5 a "D", the face would be entirely different. The ID-Data used for producing an object for display 
should not be ID-Data which is designed not to appear on-screen when entered (eg: a password), 
since the display of a corresponding object would give a rogue information on which to base 
guesses of the secret ID-Data. 

By utilising cryptography or having complex formulas to determine the sequencing of 
20 animation, the rogue programming the corresponding spoof program shall have to crack the 
cryptographic scheme in order to get the selection of character animation correct for any 
generalised attack. In the abovementioned example, a rogue will have to determine the algorithm 
for producing the face, since human beings are adept at recognising faces, and will immediately 
notice if the face displayed on the screen is incorrect. Such a technique allows for a 
25 mathematically secure, visual method to guarantee the authenticity of the software which 
generates the screen feedback. The user of the software is instructed to note their own particular 
animation sequence and to immediately discontinuing utilisation of the application 30 should that 
sequence ever change. The user may also be instructed to contact a trusted person, such as the 
supplier or operator of the application to confirm that the animation sequence they witness is the 
30 authentic sequence intended by said supplier. 

Further, the particular animation presented for a particular application 30 can be further 
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customised for each application so as to be distinct (such as by the incorporation of the 
applications name as pan of the animated image). 

Further hindrance for a rogue programmer can be created by hand coding portions of the 
animation in assembly language so as to generate the maximum possible complexity and 
5 interaction in the animation with the highest level of detail for individual workstation computers. 
This further raises a hurdle allowing for the easier detection of rogue spoof programs 22 which 
will often be written in a more convenient, higher level language (such as C or C++) which will 
also operate at a different speed, the user being instructed to look for speed differences. 

Further, animated scene timing can be utilised, providing anti-loop ing and frame removal 

1 0 detection is still catered for. The animated scene timing allows for a user to detect unexpected 
irregularities in a frequently presented animated interface. By including in the animation some 
deliberate regularity (such as the rhythmic convergence of some parts of the animation in one 
particular spot), a rogue programming a spoof program shall also have to duplicate the 
preferably complex timing events necessary to accomplish this convergence. The regular nature 

1 5 of the scene timing should be high enough so that the user expects to see certain events and 
thereby making it difficult for a rogue spoof program to copy the animation without including 
all parts of it. 

Preferably, where possible, all ID-Data is immediately encrypted which makes recovery 
of the ID-Data by a rogue through analysis of the computer program memory difficult 
20 Preferably, public-key cryptographic methods (eg: Elliptic-curve, RSA or Dime-Hellman 
cryptography) should be used making it impossible to reverse engineer the cryptographic code 
to decrypt any sensitive information should it be stolen in its encrypted form. Prohibiting all or 
most interrupts when data is to be entered and encrypting or hashing the sensitive information 
immediately so that it is only stored partially, or in an encrypted form, before re-enabling 
25 interrupts is one example of achieving this objective. 

As a further alternative, analysis of a user's personal characteristics can be included as 
part of the interface. This can include attempts at recognition of a user's typing style (duration 
of keypresses, delays between subsequent keys, choice of redundant keys, mouse usage 
characteristics, etc) or by additional authentication techniques, including smart cards, biometric 
30 inputs such as finger prints detectors etc. 

Further, the graphical animation routines can be "watermarked" by the secure ID-Data 
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eniry program code m that "hidden" information may be incorporated into the scene (for example 
"sal ted- check sums") to allow careful analysis of the output of secure ID-Data entry program 
code 3 1 to distinguish between original graphics animation and counterfeit animation. For 
example, the hidden information may be encoded in the least-significant bit of pixel data at 

5 selected locations of the animation. 

The user determinable sequence of animation can also extend to the provided audio 
animation. For example, audio and other feedback techniques including music and speaking 
tones can be played in response to particular key stroke combinations. By utilising different 
voices and/or tones and/or volumes and pitches for each keystroke or combination, the security 

10 of the application 30 can, once again, be substantially increased. The change in voice intonation 
will be readily "learnt" by a user and thereby further inhibit a rogue's ability to duplicate the same 
sequence of sounds or voices. Of course, the encoding of the voice system should be in an 
encrypted form. 

Further, upon detecting any attempt to subvert the secure ID-Data entry program code 
15 31 (eg: subsequent to detecting tampering), a notification message is preferably sent to a 
prosecuting body or the like where the application 30 is currently, or later becomes connected 
to a network such as the Internet, or by other means (eg: via Modem or by including coded 
information in public or other files). 

For application programs 30 requiring activation by a host program executed on a 
20 different computer, a secure means of activation can be incorporated into the client application 
30. The host and client intercommunication can issue challenge and response code 
authentication and verification utilising cryptographic systems such as public-key encryption 
and/or other standard means of overcoming data replay attacks and other threats designed to 
trick the secure client application 30 into activation. 
25 It would be appreciated by a person skilled in the art that the process of coding any data 

entry process utilising these techniques, together with additional techniques to protect against 
recording, and eavesdropping, and executable protection techniques may be necessary to 
improve the security of the interface. Additionally, executable encryption, additional 
authentication, and other methods are desirable in producing the protected executable. 

30 
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Summary of the Annlicator (of an improved process of security as herei nbefore described 

A preferred embodiment of the present inventions' method (hereinbefore described as the 
"applicator") by which to apply an improved process of security (as hereinbefore described) will 
5 now be described with reference to the accompanying drawings. 

Referring now to Fig. 7, there is shown a standard format utilised for storing execu tables 
on disk, often occurring in the art, and in particular in conjunction with programs run on the 
above mentioned operating systems. The standard executable 16 normally comprises a header 
section 71, a code section 72, and a data section 73. The header section 71 normally stores a 
10 standard set of iriformation required by the computer operating system 1 7 (Fig. 1) for running of 
the executable 1 6. This can include relocation data, code size etc. The code section 72 is 
normally provided for storing the "algorithmic'' portion of the code. The data section 73 
normally is utilised to store the data, such as constants, or overlays 92 utilised by the code 
section 72. 

1 5 Turning now to Fig. 6, the preferred embodiment of an applicator program 60 is shown 

which takes as its input the executable program 16 and performs an obfuscating step 61, a 
ciphering step 62 and an anti-key press and authentication step 63 (described hereafter) which 
perform various transformations on the executable program 16 to produce a new executable 
program 30 

20 The obfuscating step 61 modifies the header 7 1 (Fig. 7) of the executable 1 6 in addition 

to inserting loading code which will be described hereinafter. The cipher step 62 encrypts the 
existing executable 16 and calculates check data (eg: a checksum) for the encrypted executable. 
The anti-key press and authentication step 63 replaces various insecure system calls with safe 
equivalent code and preferably inserts code to graphically represent the integrity of said 

25 executable program. 

The newly formed executable 30 (new.exe) can be then stored on disk and the applicator 
program 60 completed, the new executable 30 replacing the old executable program 16. 

When it is desired to run the replacement executable program 30, the replaced executable 
30 (new.exe) executes the obfuscating code, previously inserted by applicator 60 The 

30 obfuscating code initially decrypts the executable program and validates the stored check-data 
before re-executing the decrypted executable. 
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The foregoing description of the preferred embodiment has been in general terms and it 
wiU be understood by those skilled in the art that the invention has general application to many 
different operating systems, including MS-DOS, Apple Macintosh OS, OS/2, Unix etc. 

The most common operating system utilised today is the MS-DOS operating system. 
5 This operating system is designed to run on INTEL x86 microprocessors and includes a large 
number of historical "quirks" which give rise to greater complexity than would perhaps be 
otherwise required when designing a new operating system from "scratch". For illustrative 
purposes, there will now be presented a specific embodiment of the preferred embodiment 
designed to operate under the MS-DOS operating system. Unfortunately, the example is quite 
10 complex as it operates in the framework of the MS-DOS operating system. Therefore, it is 
assumed that the reader is familiar with systems programming under the MS-DOS operating 
system. For an extensive explanation of the inner workings of the MS-DOS operating system, 
reference is made to standard texts in this field. For example, reference is made to "PC Intern" 
by Michael Tischer, published in 1994 by Abacus, 5370 52nd Street, S.E. Grand Rapids, MI 
15 495 1 2. A second useful text in this matter is "PC Architecture and Assembly Language" by 
Barry Cauler, published 1993 by Carda Prints, 22 Regatta Drive, Edgewater, WA 6027, 
Australia. 

The specific embodiment of the present invention will be described with reference to 
altering an "EXE" executable program under DOS in accordance with the principles of the 
20 present invention. 

Referring now to Fig. 9, there is shown the structure 90 of an executable ".EXE" program 
in MS-DOS as normally stored on disk. This structure is closely related to the structure 16 of 
Fig 7 which illustrates the more general case. The structure 90 includes a header 71, otherwise 
known in MS-DOS terminology as the program segment prefix (PSP). This is normally followed 
25 by a relocation table 91 which contains a list of pointers to variables within a code area 72 which 
must be updated with an offset address when the program is loaded into a particular area of 
memory. The operation of the relocation table is well known to those skilled in the art of 
systems programrning. The next portion of structure 90 is the code area 72 which contains the 
machine instructions for operation on the x86 microprocessor. This is followed by a program 
30 data area 73 which contains the data for code area 72. Finally, there may exist a number of 
overlays 92 which contain code which can be utilised in a known manner. 
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Referring now to Fig. 8, there is shown the structure of EXE file header 7 1 in more detail. 
The table of Fig 8 being reproduced from page 750 of the above mentioned Tischer reference. 
It should be noted that the header 71 includes a number of fields including, for example, a pointer 
81 to the start of the code 72 (Fig 7) and a pointer 82 to the relocation table 9 1 (Fig.9) 
5 in the specific embodiment, the applicator program 60 (Fig. 6) proceeds by means of the 

following steps: 

(1) The executable program 16 is opened for reading and a determination made of its 

size. 

(2) The header 71 (Fig.9) of executable program 1 6 is then read in and a copy is stored 
10 within applicator program 60. A copy of the header 71 is written out to form part 101 of the 

new.exe file 30 as illustrated in Fig. 1 0. 

(3) Next from the fields 81, 82 of the header 71 (Fig. 8) a determination is made of the 
size of relocation table 91 of executable program 16. 

(4) Next, determination is made of the size of the executable code 72 and data portions 

15 73. 

(5) The relocation table 9 1 is then read into the memory of the applicator program 60. 
As noted previously, the relocation table 91 consists of a series of the pointers to positions 
within code segment 72 which are required to be updated when loading the program.exe file into 
memory for execution. The relocation table is sorted 93 by address before being written out to 

20 the new.exe executable file at position 102. 

(6) As noted previously, the relocation table 91 consists of a series of pointers into 
code area 72. A determination is made of the size of a code, known as the "netsafe 1 " code 104, 
the contents of this code will be described hereinafter. Next, a search is conducted of the sorted 
relocation table 1 02 to find an area between two consecutive pointers within code section 72 

25 which is of greater magnitude than the size of netsafe 1 code 104. This area 94, designated part 

B in Fig.9 is located. If this code portioned 94 cannot be located the applicator program 60 

exists with an error condition. 

Upon finding code portion 94, the code portion 95, also denoted part A is encrypted and 

copied across to form new code portion 103. Code portion 94 is then encrypted and copied to 
30 an area 105 of new.exe 30. The netsafe 1 code 104 is then inserted by applicator 60. Code 

portion 96, also denoted part C is encrypted and copied across to form code portion 106. Data 
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portion 73 and overlay portion 92 are copied into new.exe 30 as shown. A second portion of 
obfuscating code, denoted "netsafe 2" 107, the contents of which will be described hereinafter, 
is then inserted after overlays 92 and before code portion part B 105. 

(7) The header 1 01 is then updated to reflect the altered layout of new.exe executable 
5 30. Additionally, the initial address 109 of execution stored in header 101 is altered to be the 

start of netsafe 1 portion 104. 

(8) As mentioned before, code portions 103, 106 and 105 are subjected to encryption 
or eocipherment in accordance with step 62 of Fig.6. The encryption scheme utilised can be 
subjected to substantial variation. In this embodiment, the DES standard encryption scheme was 

1 0 utilised. This scheme relies on a fifty-six bit key for encryption and decryption and is well known 
in the art. 

Once encrypted, it is necessary to store the decryption key in new.exe executable 30. 
A number of different methods can be utilised to store the key. The preferred method is to 
spread portions of the key to different positions within the executable 30. For example, bits of 

15 the key can be stored within the netsafe 1 code 104 and netsafe 2 code 107. Additionally, bits 
of the key can be stored within header portion 101. Also, it is envisaged that bits of the key can 
be stored in the condition codes which are a consequence of execution of various instructions 
within netsafe 1 area 104 and netsafe 2 area 107 and/or the operating system 17 (Fig. 5), with 
the overall requirement being that the key can be later extracted using a predetermined 

20 algorithm. 

(9) The next step is to patch the address of the start of code area 72 and netsafe 2 code 
area 107 into the required locations within netsafe 1 area 104. 

The netsafe 1 area is then written to the file containing new.exe executable 30. 

(10) The area 106 is then encrypted as aforementioned and written to the executable 30 
25 followed by overlays 92 and encrypted netsafe 2 code portion 107. 

(11) As will become apparent hereinafter, upon execution ofnew.exe executable 30, 
netsafe 2 area 107 is responsible for loading code portion 105 over the top of netsafe 1 area 104. 
Therefore, it is necessary to write the relevant addresses of the start and end of code portion 
94 to the required position within netsafe 2 area 107. 

30 (12) As will be described hereinafter, netsafe 2 area 107 is also responsible for 

decrypting the encrypted portions of codes 103, 104, 105, 106, and 107 and hence the netsafe 
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2 area 1 07 must also store this combined code size for later use on decryption. 

Finally, a overall checksum for new.exe 30 is calculated and stored at the end of the file 
at position 108. This checksum is later used to verify the decryption procedures' success and 
to prevent the execution of "scrambled" code, which would be the result if new.exe 30 were 
5 tampered with. 

As will be further described hereinafter, netsafe code areas 104 and 1 07 contain code to 
decrypt the encrypted areas of the new.exe 30, to repatch code portion 105 back to its original 
position, and to replace potentially insecure routines or easily spoofed screens normally utilised 
by the application (eg: unsafe keyboard drivers) with an alternative safe form of routine. 

1 0 Upon execution of the new.exe executable 30, the executable starts at the start of netsafe 

1 , area 1 04 (Fig. 1 1 ), as this address has been previously patched into position 109 (fig. 1 0) of 
header 101 (Fig. 10). The netsafe 1 area 104 then performs the following steps (Al) to (A10): 
(Al) The first step is to disable all the interrupts apart from those necessary for 
continued operation of the computer device 1 8 (Fig. 1) (for example, memory refresh cannot be 

1 5 disabled). The disabling of interrupts includes the disabling of the keyboard interrupt in order 
to stop amateur "code snoopers" from determining the operation of the code area 104. 

(A2) The next step is to interrogate the calling environment of the operating system 
stack to ensure that the program new.exe was not called by a debugging program which is 
tracing the operation of new.exe. Additionally, the data variables necessary for operation of 

20 netsafe 1 code area 1 04 are defined to be on the operating system stack (Refer Address 0EH and 
1 OH in Ftg.8). This stack will change unexpectedly when in a code snooping or debugging 
environment and will cause the debugger to crash, thereby stopping a it from following the 
operation ofnew.exe executable 30. 

(A4) The interrupt trap addresses are then altered in a two stage process. The first stage 

25 resets a first part of the SEG:OFF address format and occurs at this point with a second stage 
occurring at a later time as will be further described herein below. By staging the alteration of 
interrupt trap addresses, any code snooper will be further confused as said trap addresses will 
initially be garbage. 

(A5) Any input from the keyboard is further disabled by informing the MS-DOS 
30 operating system to ignore any received keys. 

(A6) The second stage of the revectoring of the normal debugging interrupts is then 
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applied so that the normal debugging interrupts can be used by the decryption code, to be 
described hereinafter, thereby making debugging almost impossible. 

(A7) A check is then made to ensure that the above processes have been successful in 
that the debugger interrupts do not point to any debuggers, the keyboard is still disabled and the 
5 operating system has disabled the acceptance of keys from the keyboard. 

( A8) The key for decryption is then reconstructed utilising the reverse process to that 
utilised in storing the information located in the key. 

(A9) Turning now to Fig. 1 1, there is shown the standard format of the executable 
new exe 30 when executing in memory. As will be well known to those skilled in the art, an 
10 executing program under the MS-DOS system will include a stack 1 1 1 and work space 112. A 
memory allocation (Malloc) call is then done to set aside an area 1 13 for the loading in of the 
netsafe 2 code 107 of Fig. 10. The disk copy of new.exe 30 (having the format shown in Fig. 10) 
is then opened by the netsafe 1 code 1 1 5 and an encrypted copy of netsafe 2 code 107 (Fig. 1 0) 
is then loaded in from the disk file, decrypted and stored in memory area 113. The relocatable 
15 pointers of the code contained within the netsafe 2 code 1 13 are then updated to reflect the 
position of the executable in memory. 

(A 10) Control is then passed to netsafe 2 code 113. 

The code area netsafe 2, 1 1 3 then performs the following steps (B 1 ) to (B4): 

(Bl) The portion of code of the disk copy denoted part B, 105 (Fig. 10) is read in from 
20 disk in an encrypted format and written over the old netsafe 1 code 115. 

(B2) As will be further described hereinafter, the netsafe 2 area 1 13 includes a number 
of keyboard routines which are preferably stored in an encrypted format. Therefore, the next step 
is to apply the decryption to any of the encrypted areas of netsafe 2 code area 113. After 
decryption, the netsafe 2 area 1 13 is checksummed and the result is tested against a prestored 
25 checksum to ensure the integrity of netsafe 2 area 113. 

(B3) The disk copy of the new.exe is then again read in and checked against prestored 
check data to ensure that it has not been changed. Additionally, an attempt is made to read past 
the end of file of the disk copy ofnew.exe 30 (Fig. 1 0) to ensure that no extension (eg: viral) has 
occurred. 

30 (B4) The encrypted portions of the memory copy (Fig. II) ofnew.exe are then 

decrypted utilising the key and once decrypted, the decrypted portions are again checked and 
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tested against predetermined data 

The next step in execution of the netsafe 2 code 113, is to replace insecure (eg: 
keyboard) system routines with a more secure method. Referring now to Fig. 12, there is shown 
the current state of the new.exe executable in memory. The insertion of the more secure system 
5 routines then proceeds in accordance with the following steps (CI) to (C5): 

(Cl) Firstly, a second memory allocation is done to set aside an area 5 1 (Fig. 1 3) for the 
storing of the secure hardware routines (eg: keyboard). These routines are then copied from 
their area within netsafe 2 code 1 13 to the memory area 5 1 . 

(C2) Next, the ID-Data entry routines which are normally activated by the interrupt table 
10 131 when dealing with ID-Data input are altered such that, rather than pointing to corresponding 
areas of the MS-DOS operating system 1 7, they point to the corresponding secure area 5 1 . 
These interrupts include interrupt 9 which occurs when a key is pressed on a keyboard, interrupt 
29h which reads a key and interrupt )6h which tests for the presence of a key. 

(C3) The executable 30 (Fig. 13) is then ready for execution and the registers are 
I S initialised, the memory area 113 deallocated & control passes to the original start address of 
executable program 16. 

(C4) It will be evident, that when executing, all keyboard calls (or other ID-Data entry 
calls, if other than keyboard) will be passed to keyboard (or other) routines 5 1 with the keyboard 
hardware being interrogated directly by keyboard routines 51 to return information to the calling 
20 program Keyboard routines 5 1 include a copy of the correct interrupt vector addresses for each 
keyboard routine and each time they are called, a check is made of the interrupt table to ensure 
that it has not been altered. Preferably, keyboard routines 5 1 protect the keyboard hardware by 
issuing controller reset or similar commands to flush the keyboard data out of the circuitry after 
said data is retrieved to prevent hardware eavesdropping, or routines 5) utilise the protected 
25 mechanisms of the central processor to protect said hardware from eavesdropping. 

(C5) When the executable 30 terminates, interrupt 21h (an MS-DOS standard) is called. 
This interrupt is also revectored to a corresponding area of routines 51 . The termination code 
of keyboard routine area 51 restores the correct interrupt pointers in interrupt table 13 1 to point 
to the MS-DOS operating system 17, and clears the no-longer-needed program and data from 
30 memory before returning to the DOS operating system by calling the real interrupt 2 1 . 

The foregoing describes only one particular embodiment of the present invention, 
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paracularly to the operation of the MS-DOS operating system It will be evident to those skilled 
in the art, that the principles outlined in the particular embodiment can be equally applied to 
other operating systems in accordance with the objects of the present invention. Further, 
combinations, variations and/or modifications, obvious to those skilled in the art, can be made 
5 to the present invention. All such combinations, variations and/or modifications should be 
considered to fall within the scope of the invention as broadly hereinbefore described and as 
hereinafter claimed. 
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The claims defining the present invention are as follows: 

1 . A computer system having software having input routines with enhanced security 
features for entry of ID-Data including: 
a processor; and 

5 a memory, wherein said software stored in said memory when executed by said processor 
includes: 

anti-spy techniques within said input routines which prevent or hamper eavesdropping; 
detect tampering of said software which, upon detection of tampering, either disallow the 
subsequent entry of ID-Data into said input routines, or which invalidate said ID-Data in 
0 order to disallow current and subsequent access to that which said ID-Data would have 
otherwise allowed; and 

further including at least one of the following code contained in said software: 
code to automatically scan memory of said software one or more times before or during 
execution of said software to detect tampering; 
15 code to store or communicate details of detected tampering for later examination, said 
details including all or part of said tampered software, or other information available to 
said tampered software from said computer system; and 

code to prevent, or detect and subsequently prevent tracing, or misleading code debuggers 
and the execution of tracing by utilising debugger trap facilities for the normal operation of 
20 said security-enhanced software, or monitoring system timers or timing-sensitive 
instructions or monitoring CPU stack contents or monitoring system buffers to detect the 
activity of code debuggers, or disabling facilities such as, the keyboard, serial ports, printer 
ports, mouse, screen or system interrupts in order to hamper code debuggers, or testing that 
the disabled status is still true of said facilities to detect code debuggers, or utilising system 
25 interrupts which would ordinarily be used by code debuggers for the custom purposes of 
said security -enhanced software, or utilising CPU instruction caches together with self- 
modifying code to mislead code debuggers, or scanning or interrogating the operating 
system or exccutable-load-process to detect code debugger instructions or environments, 
characterised in that the program optionally includes a process or multiple processes which 
30 are resident or child processes of said security-enhanced software which execute during 
system interrupts of after the parent process has terminated in order to hamper tracing. 
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2. A method of altering an original executable program to form on altered executable 
program having increased security, said method including the steps of: 
(a) inserting obfuscating code into a first number of predetermined areas of said executable 
program; and. 

5 (b) encrypting portions of said executable program for later decryption upon execution; 
such that, upon execution of said altered executable program, said execution includes the 
steps of; 

(c) decrypting the altered executable program; and 

(d) restoring said altered executable program to said original executable program. 

10 

3. A method as claimed in claim 2 further including one or more of the following: 
said obfuscating code include replacement codes for insecure system routines and said 
method further includes the step of (e) replacing the execution of said insecure system 
routines with said replacement codes; 
1 5 said steps (c) and (d) occur while simultaneously substantially disabling eavesdropping on 
the operation of said steps (c) and (d) by any rogue program; 

said step (a) includes inserting a portion of said obfuscating code into the code area of said 
original executable program; and, 

said step (e) includes altering portions of an interrupt vector table to point to said 
20 replacement codes; 

said step (b) includes the storing of a decryption key in a plurality of predetermined areas 
of said altered executable program, 

said predetermined areas include the condition codes of predetermined instructions of said 
altered executable program. 

25 

4. A method of providing for a secure entry of ID data or input information in a computer 
system including: 

a. activating a visual display or animation or audio feedback (hereinafter called an 
audiovisual component) as part of said secure entry of said ID data or said input 

30 information so as to substantially hamper cumulation of a secure entry process; and 

b. audio/visual component feedback including at least two of: 
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i) at least part of said input information; 

ii) at least part of information based upon some transformation of at least part of the 
software including said audio or visual component or the computer operating system upon 
which said audio or visual component operates. 

5 

5. A method as claimed in claim 4 wherein said audiovisual component has repeatable 
characteristics during subsequent invocations of said entry process, such that said 
audiovisual component on each invocation of said entry process has a predetermined 
resemblance to the audiovisual component of all other invocations of said entry process. 

1 0 or, said audiovisual component is varied in accordance with the information entered. 

6. A method as claimed in claim 4 wherein said audiovisual component includes moving 
parts and/or includes 2,5-dimcnsional animation or 3-dimensional animation, and/or, said 
audiovisual component includes a representation of said input information, preferably 

1 5 including (a) display of a single graphical object, and/or (b) production of a single audio- 
feedback sequence, after the entry of all or part of said input information. 

7. A method as claimed in claim 6 wherein said input information representation includes 
animation of input characters and/or audible or other feedback determined by input 

20 characters, wherein the representation of said input characters may optionally vary for each 
character based on the result of a predetermined transformation of the preceding inputted 
characters, wherein said transformation utilises cryptographic or hashing methods. 

8. A method as claimed in claim 6 wherein: the ease by which faithful replication of said 
25 audiovisual component is substantially reduced by inclusion in said audiovisual component 

the techniques of on screen shadow rendering and/or spot or flood scene fighting effects 
and/or scene or object shading and/or transparent or translucent objects and/or shiny, 
reflective, or mirrored objects and/or real-time animation roughly obeying real world 
gravitational effects and/or single-image-random-dot stereogram bitmaps or backdrops 
30 and/or partial scene masking effects and/or full or partial scene distortion or diffraction 
effects and/or animated objects designed to resist simple hidden-surface removal 
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techniques and/or animated bitmaps and/or audible echo effects and/or differing audio 
voice e fleets and/or differing audio volume and/or differing audio tones or pitches; 
wherein, said audiovisual component is optionally immediately recognisable to human 
beings and includes information which identifies to the user the application to which said 
5 audiovisual component belongs; wherein, the ease by which faithful replication of said 
audiovisual component may optionally be further reduced by inclusion in said audiovisual 
components animation object movement timing such that at near regular and frequent 
intervals regularities occur which are obviously recognisable to users of said entry process; 
and preferably, wherein, said entry process including said audiovisual component utilises a 
10 substantial portion of the computational resources of said computer system; and, wherein, 
said entry process code responsible for said audiovisual component is coded in the 
assembly language of the computer system preferably wherein recording said audiovisual 
component by said computer system is disabled. 

15 9. A method as claimed in claim 4 wherein (a) the facility to suspend or swap-out said 
entry process is either disabled, or, (b) immediately upon suspension request, said entry 
process is protected against subsequent examination by encryption or by termination and 
removal from memory or said entry process, or, (c) where the facility to allow the central 
processor or processors of said computer system to execute code other than the code of, or 

20 the code necessary for said entry process is either disabled or else said entry process is 
protected against examination. 

1 0. A method as claimed in claim 4 wheTein: said entry process hampers simple recording 
by utilising the maximum practicable use of audiovisual framerate, and/or audiovisual 
25 resolution, and/or screen colours; and/or, audiovisual design in said audiovisual component 
on said computer system, and/or said entry process hampers the compression of recorded 
output from said audiovisual component by utilising high audiovisual entropy and/or by 
the inclusion of random or other noise in said audiovisual component; wherein, said 
audiovisual component preferably includes continuous output such that the looping of only 
30 a subset of said output shall not reproduce a copy largely indistinguishable to said 
audiovisual component. 
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11. A method as claimed in claim 4 wherein said ID-Data or said input information is 
encrypted by a cryptographic process or hashed immediately upon entry and a plain text 
equivalent is not stored by said computer system; and/or, wherein disablement of one or 
more interrupt instructions (or equivalent CPU devices) is utilised to protect said 

5 cryptographic or said hash process of said ID-Data to hamper the recovery of said ID-Data 
by processes other than said entry process. 

12. A method as claimed in claim 4 wherein said input routines or said secure entry 
process prevents the re- vectoring of system interrupts in order to protect said ID-Data or 

10 said input information form being stolen, by means of re-applying interrupt vector pointers 
one or more times and/or by means of examining interrupt assignments in order to perform 
a predetermine d function should the expected assignments be altered. 

1 3. A method as claimed in claim 4 wherein in order to further authenticate and/or identify 
1 5 said user, additional aspects of said ID-Data or said input information are used including 

the duration of individual key presses and/or mouse button presses and/or the delay 
between subsequent individual key presses or mouse button presses and/or the user's 
selection of particular keys when more than one equivalent exists andVor the acceleration or 
velocity characteristics of mouse usage and/or where said input information includes 
20 information from other sources including biometric and/or smartcard information. 

14. A method as claimed in claim 4 wherein said input routines or said secure entry 
process authenticates itself using (a) executable code checksums of RAM or other images 
of its own executable code and/or data, (b) and/or comparison of memory with other stored 

25 copies of said executable code, (c) and/or decryption of said entry process (d) and/or 
detection of executable tampering by examination of the executable's environment (e) 
and/or comparison of executable size with expected values (f) and/or by attempting to read 
past the end of the executable file to determine that the size is correct; parts (a) through (f) 
occurring either upon initial load or during or after execution one or more times or 

30 continually during execution. 
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15. A method as claimed in claim 4 wherein said input routines or said secure entry 

process: 

makes use of system interrupts to monitor itself in order to delect alternation of itself; 
incorporates means by which to notify and/or transmit authentication failure details to a 
5 third person or process should said self authentication fail, records a log of the usage 
and/or details of the user of said input routines or said secure entry process; 
incorporates warning s within the executable image indicating that examination and/or 
tampering is prohibited; 

stores loading and/or decryption routines are stored within the executable image in such a 
1 0 way as they initially replace other entry process routines and upon successful decryption 
and/or authentication, said other entry process routines are replaced; 

hampers executable-code tracing through control-flow changes in debug environments or 
through disabling one or more system interrupts and/or disabling the keyboard and/or 
disabling the mouse or other input device s and/or making use of the program stack pointer 

1 5 to discern existence of a debug environment and/or utilising debug interrupts for program 
code operation and/or self-modification of executable code and/or examination of CPU 
flag registers and/or verification of disabled interrupts still -disabled state and/or 
verification of disabled keyboards still-disabled state and/or loading additional executable 
code into memory during execution; 

20 includes obfuscating assembly language dummy operation codes or instruction prefixes 
inserted after one or more unconditional branches to hamper executable disassembly 
and/or decompilation and/or reverse engineering; 

becomes securely activated by its activation process anaVor a host or server computer using 
a challenge/response activation protocol or using public or private key cryptographic 
25 methods; and/or becomes stored outside of said computer system memory in encrypted 
form and/or where said entry process employs techniques to hinder executable-code 
tracing and/or executable-code disassembly or disclosure or decompilation and/or 
executable-code tampering and/or executable-code hot-patching and/or reverse- 
engineering and/or pre, in, or post-execution executable-code recording, copying, 
30 eavesdropping or retrieval and/or theft of said input information from keyboard hardware 
or software or drivers. 
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16. A method as claimed in claim 4 wherein said audiovisual component contains 
watermark information incorporated into the scene to allow close inspection of said 
audiovisual component to distinguish between the genuine process and a close replica. 

17. A computer program product for requiring the entry of ID-data for access thereto, said 
program characterised by having an enhanced security structure or features to prevent ID- 
data eavesdropping or theft or to ensure authenticity, having: 

a computer readable storage medium for holding codes; and 
further including one or more of the following: 

code for preventing ID-data eavesdropping, by communicating directly with input 
hardware of a computer; 

code for preventing disassembly thereof, said code for preventing disassembly including 

obfuscating inserts, dummy instructions or executable encryption; 

code for preventing tampering therewith, said code to prevent tampering including: 

code for reading its own image including external or internal memory images or 

calculating check data associated therewith; and 

code for comparing said read image or calculated check -data with an authentic image or 
check-data to prevent execution-tracing, and code for disabling interrupts or for 
performing timing-sensitive instructions between interrupts; or, code for ensuring 
authenticity, by providing an audio or video feedback to an output device to be viewed or 
heard by an operator. 

18. A method for enhancing the security of access to user identification data by software 
on a computer system including: 

using an obfuscating process to hamper or prevent eavesdropping: 
detecting tampering; and 

if tampering is detected, selecting an action of either disallowing subsequent entry of the 
user identification data into input routines or invalidating the user identification data in 
order to disallow current and subsequent access to the user identification data. 
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19. The method of claim 18, wherein program code that is vulnerable to eavesdropping is 
replaced with equivalent program code wherein said vulnerability is removed, and wherein 
said equivalent program code communicates directly with the hardware of the computer 
while disabling functions thai would permit rogue software to eavesdrop. 

5 

20. The method of claim 18, further including using encrypting or inserting dummy 
instructions in said user identification data to hamper or prevent eavesdropping. 

21. The method of claim 18, wherein detecting tampering includes code that re-reads the 
1 0 code's own external-image or the code's internal memory image and compares a calculated 

checksum of said image with a pre-calculated checksum. 

22. A computer system having software having input routines with enhanced security 
features for entry of ID-data, substantially as herein described with reference to the 

15 accompanying drawings. 

23. A method of altering an original executable program to form an altered executable 
program having increased security, substantially as herein described. 

20 24. A method of providing for secure entry of ID-data to input information in a 
computer system, substantially as herein described. 

25. A computer program product for requiring the entry of ID-draft for access thereto, 
substantially as herein described with reference to the accompanying drawings. 

25 
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26. A method for enhancing the security of access to user identification data by 
software on a computer system, substantially as herein described. 

DATED this 20th day of June, 2000 

CHRISTOPHER NATHAN DRAKE 
PATRICK ARTHUR ROSE 
By Their Patent Attorneys 
DAVIES COLLISON CAVE 
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